"XPNET 3.1 Interim Bug Fixes (IBFs) and Enhancements - TCP" SCR# Change Description ----- ------------------ SCR SSL TCPCLI/SSLCLI - rel3_ver0_sslc00_051215 15-DEC-05 rel3_ver0_tcpc28_051215 rel3_ver0_tcpl21_051215 rel3_ver0_ctse16_051215 TCPSRV/SSLSRV - rel3_ver0_ssls00_051215 rel3_ver0_tcps32_051215 rel3_ver0_tcpl21_051215 rel3_ver0_ctse16_051215 TCPTPLO - $data01.n30tcpl.tcp05po CTSETPLO - $data01.n31ctse.ctse01po STGKM - Last Modified - 11NOV2005 9:22 ROOTCERT - Last Modified - 19MAY2005 10:06 Reference: Internal/GA of SSL. Symptom: None. Problem: None. Change: Added functionality to handle SSL over a TCPIP connection. This enhancement uses the SafeTGate SSL Library. Added functionality for SSL to refresh the Licence file , Certfile and the Rootfile. The code will also look for the latest version of the configuration file to use when refreshing and when starting. The version processing will require the config file to be in the following form xxYYMMDD. Implementation: Move in the new SSLSRV, SSLCLI and CTSE modules. Stop any of the associated stations. Stop and re-start SSLSRV and/or SSLCLI. Re-start the previously stopped stations. See implementation guide. Dependencies: XP 3.0 - Requires *** CTS27 *** due to scr3246. XP 3.1 - Requires *** CTS02 *** due to scr3246. SCR #3313 Files unique 08-MAR-06 for XPNET 3.0 Accelerates -------------- ----------------------- XPNET.ocaALL - u30oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u30oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u30alib.oca00as APPLIB XPNET.ocaNET - n30base.oca00as NETWORK XPNET.ocaNETAD - n30audr.oca00as NETADRD XPNET.ocaNCP - s30ncp.oca00as SVNCP XPNET.ocaNCPI - s30ncpi.oca00as SVNCPI XPNET.ocaNLIB - n30nlib.oca00as NLIB XPNET.ocaPREG - s30pre.oca00as PREGEN XPNET.ocaSKELB - n30sutl.oca00as SKELB XNLIB.ocaSMPL - u21smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u30xlib.oca00as XNLIB Files unique for XPNET 3.1 Accelerates -------------- ----------------------- XPNET.ocaALL - u31oca.ocaA00as all TNS objects on subvol XPNET.ocaBUILD - u31oca.ocaB00as called by all OCA routines XPNET.ocaAPPL - u31alib.oca00as APPLIB XPNET.ocaNETAD - n31audr.oca00as NETADRD XPNET.ocaNCP - s31ncps.oca00as SVNCP XPNET.ocaNCPI - s31ncpi.oca00as SVNCPI XPNET.ocaNLIB - n31nlib.oca00as NLIB XPNET.ocaPREG - s31pre.oca00as PREGEN XPNET.ocaSKELB - n31sutl.oca00as SKELB XNLIB.ocaSMPL - u31smpl.oca00as (sample OCA file) XNLIB.ocaXNLIB - u31xlib.oca00as XNLIB Files for XPNET 3.0 & 3.1 Accelerates --------------- ----------------------- XPNET.ocaAUDP - u30audp.oca00as AUDPRO XPNET.ocaPATH - n21path.oca00as PATH XPNET.ocaPWR - n21pwr.oca00as PWR XPNET.ocaPWS - n30pws.oca00as PWS XPNET.ocaQFI - n30qfi.oca00as QFI XPNET.ocaQFILD - n30qfi.ocal00as QFILOAD XPNET.ocaTCPC - n30tcpc.oca00as TCPCLI XPNET.ocaTCPS - n30tcps.oca00as TCPSRV XPNET.ocaUDP - n30udp.oca00as UDP SCRIBE.ocaEMSP - n30empp.oca00as EMSPERUS Reference: Internal, case 408953 Symptom: None. Problem: None. Change: Developed TACL routine files which can be used by customers to accelerate TNS objects for Itanium machines using the HP Object Code Accelerator (OCA) utility. See the list of files above, with the respective name of the object(s) they accelerate. Implementation: Install the new files on the XPNET, XNLIB and SCRIBE subvols as indicated. To OCA-accelerate objects on the XPNET subvolume, the OCAALL file can be run to accelerate all the objects it can find (required and optional) on the XPNET subvolume or each individual object can be accelerated separately using its respective OCA file. Note that OCAALL first performs a checklist of the files it can accelerate and then invokes the respective individual OCA files, as necessary, to OCA-accelerate each module. On the SCRIBE subvolume, run the OCAEMSP file to accelerate the EMSPERUS object. If the XNLIB object is used, run the OCAXNLIB file on the XNLIB subvolume to accelerate the XNLIB object. The OCASMPL TACL routine file can be used for accelerating TNS user applications which use the XNLIB run-time library. Just FUP DUP OCASMPL to the location of the object that you want to accelerate, modify the DUP'ed macro file to point it to the correct object file and create the correct target file and then run it from the TACL prompt. You can add options to suppress warnings as necessary. The TACL routines are designed to create a new object of the same name with an "A" appended to the end of the object filename (e.g. when the SVNCPI object is accelerated, a SVNCPIA accelerated object is created). If the OCA acceleration is successful, the original object is named to a ZZOCnnnn file and the "A" file is renamed to the original object file. You can purge the ZZOCnnnn file that was created as procedures warrant. Stop and restart the object if necessary. The HP OCA utility is available with the H-series NonStop OS for Itanium machines. Note also that the HP OCA utility is available with the G-series NonStop OS starting with G06.27. OCA accelerating an object on a non-Itanium system does not modify the performance of the object on that system, but does allow the object to run with optimal performance once it is moved to an Itanium system. Dependencies: None. SCR #3316 TCPCLI/SSLCLI - rel3_ver0_sslc01_060619 19-JUN-06 rel3_ver0_tcpc29_060619 rel3_ver0_tcpl22_060619 rel3_ver0_ctse17_060619 TCPSRV/SSLSRV - rel3_ver0_ssls01_060619 rel3_ver0_tcps33_060619 rel3_ver0_tcpl22_060619 rel3_ver0_ctse17_060619 TCPTPLO - $data01.n30tcpl.tcp08po STGKM - Last modified - 16MAR2006 10:54 ROOTCERT - Last Modified - 10FEB2006 21:27 Reference: Internal Symptom: None. Problem: None. Change: 1). Updates to the SSLLIB. 2). Moved redundent SSL code from the Server and Client line handlers to the shared library. 3). Added a Warning log message to the Client that alerts when a CONNECT is attempted when the Certificate has expired. 4). Modified the naming convention for the SSLCONFIG file. a). The first two characters of the a dated config file can be any two alpha characters. Previously they were required to be "SS". b). The config file can now be any valid filename it does not have to a dated filename. In this case Implementation: Move in the new SSLSRV, TCPSRV, GOTCPSRV and CTSE modules. Stop any of the associated stations. Stop and re-start SSLSRV and TCPSRV. Re-start the previously stopped stations. See implementation guide. Dependencies: XP 3.0 - Requires *** CTS27 *** due to scr3246. XP 3.1 - Requires *** CTS02 *** due to scr3246. SCR #3340 GOTCPSRV - $data01.n30tcps.gotcps07 10-JAN-06 GOTCPCLI - $data01.n30tcpc.gotcpc06 Reference: Case 406378 Symptom: None. Problem: The CTS/E default MAXBUFLEN in 4095 but the GO file indicates the default is 7000. Change: Changed the GO file to match the CTS/E source code. Implementation: Install new GOTCPCLI and GOTCPSRV files. Dependencies: None. SCR #3355 TCPCLI/SSLCLI - rel3_ver0_sslc03_060919 19-SEP-06 rel3_ver0_tcpc30_060919 TCPSRV/SSLSRV - rel3_ver0_ssls03_060919 rel3_ver0_tcps34_060919 TCPTPLO - $data01.n30tcpl.tcp09po Reference: ACI Internal Symptom: None. Problem: None. Change: Added code to handle Broken Socket Detection. Station Userdata can be configured as following: -B+ - uses 10 seconds as the default -BT30+ - sets the interval to numerical value after the T in -BTxx+ The CTSE will use the default or configured time as described above. If no traffic is detected within the time period the CTSE will send the zero length message. This configuration will enable the (CTSE) TCPSRV/CLI and SSLSRV/CLI to send a zero length message that adheres to the length indicator configured. -0 - zero length message will consist of two bytes of binary zeros. -1 - zero length message will consist of two bytes that contain a binary 2 -2 - zero length message will consist of four bytes of binary zeros -3 and -4 not supported. -5,L4,F0,TA - zero length message will consist of four bytes of ASCII zero's. Other -5 configurations are possible where the length field will indicate 0 bytes of actual data. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3356 TCPCLI/SSLCLI - rel3_ver0_sslc03_060919 19-SEP-06 rel3_ver0_tcpc30_060919 TCPSRV/SSLSRV - rel3_ver0_ssls03_060919 rel3_ver0_tcps34_060919 TCPTPLO - $data01.n30tcpl.tcp09po Reference: ACI Internal Symptom: None. Problem: None. Change: Added enhanced tracing facilities for the SSLSRV and SSLCLI. The PARAM in the SSL CONFIG file "TRACEFILENAME" is no longer used. SSL Tracing is now initiated from NCPCOM. The trace can be started and stopped while the SSLSRV or SSLCLI continues to run. The following commands are used. TELL EXTERNAL $DSRV.#SSLTRCE,"START $VOL.SUBVOL.FILE" If the trace file already exists it will be purged then a new one with the same name will be created. TELL EXTERNAL $DSRV.#SSLTRCE,"STOP" TELL EXTERNAL $DSRV.#SSLTRCE,"ABORT" TELL EXTERNAL $DSRV.#SSLTRCE,"WRAP" TELL EXTERNAL $DSRV.#SSLTRCE,"NOWRAP" TELL EXTERNAL $DSRV.#SSLTRCE,"FILESIZE val" default 4000K TELL EXTERNAL $DSRV.#SSLTRCE,"RECSIZE val" default 2K TELL EXTERNAL $DSRV.#SSLSTAT,"TRACE" Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3361 TCPCLI/SSLCLI - rel3_ver0_sslc04_061030 30-OCT-06 rel3_ver0_tcpc31_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 TCPSRV/SSLSRV - rel3_ver0_ssls04_061030 rel3_ver0_tcps35_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 CTSEPLO - $data01.n30ctse.ctse07po Reference: Case #420754 Symptom: After a network outage XPNET TCPIP station logs a message indicating a Guardian error 210 ( device ownership changed ) and that it is transitioning from the STARTED state to SUSPENDED state. However a status from NCPCOM shows that the station is in the STARTED state. The client is unable to send messages to this station. Problem: There were two problems. 1). The code was not setting the recv_nw_pending flag to false after a recv error. When XPNET was notified about the error 210 it went into suspend logic and sent a CTS_SUSPEND request to TCPSRV. TCPSRV checks the recv_nw_pending flag to deteremine if it needs to post a RECV_NW. The recv_nw_pending flag was still TRUE because it was never set after the RECV_NW completed with the error 210. TCPSRV never reposts the RECV_NW. 2). On receiving the CTS_SUSPEND TCPSRV code incorrectly signaled the FSM event CTS_SUSP_NOT when it should have signaled CTS_SUSP_OK, because of this XPNET was never notified that the SUSPEND completed and NCPCOM reported station in the STARTED state. Change: Added code to set the recv_nw_pend flag to false on a recv completion with an error. Added code to FSM event CTS_SUSPEND_OK on recepit of a CTS_SUSPEND request from XPNET. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3362 TCPCLI/SSLCLI - rel3_ver0_sslc04_061030 30-OCT-06 rel3_ver0_tcpc31_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 TCPSRV/SSLSRV - rel3_ver0_ssls04_061030 rel3_ver0_tcps35_061030 rel3_ver0_tcpl25_061030 rel3_ver0_ctse19_061030 CTSEPLO - $data01.n30ctse.ctse07po Reference: Case #401567 Symptom: The following is logged by EMSPERUS: ERROR: EMSTEXT FAILED ON ATTEMPT TO PRODUCE TEXT FOR EVENT UPPER WORD OF ERROR VALUE IS 12 LOWER WORD OF ERROR VALUE IS 14 05-10-04;11:35:02.790 \K9.$SRV ACI.XPCTSE.3000 1008 Backup process ? created. Problem: CTSE logs the above messaage with the xpctse-tkn-phandle token. This token instructs EMS to resolve the PHANDLE to a printable form to log. If the process is no longer running when EMS attempts to resolve the PHANDLE an error occurs and the above error is logged. Change: Changed the code to resolve the phandle to a string and log the message using the xpctse-tkn-char-var token. EMS will now store the PPD name of the process and can log message 1008 when the process no longer exists without the error. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3370 TCPCLI/SSLCLI - rel3_ver0_sslc05_070202 30-NOV-06 rel3_ver0_tcpc32_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 TCPSRV/SSLSRV - rel3_ver0_ssls05_070202 rel3_ver0_tcps36_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 CTSE - rel3_ver0_ctse20_070202 STGKM - $data01.u10ssll1.stgk03 Last modified - 14FEB2007 11:28 ROOTCERT - $data01.u10ssll1.rootct03 Last Modified - 05JAN2007 15:27 Reference: ACI Internal. Symptom: TCPSRV dumps. A server process using the SafeTGate SSL Library is getting a time out error [40] from the INSESSION_AWAITIOX function ( FNum of -1 ) if : - the SESSIONREUSE parameter is set to YES/ON; and - the SESSIONTIMEOUT parameter is greater than 20 minutes; and - there was no traffic or any other activity within the process after the session was established. Problem: SSLLIB is returning a -1 filenum on an AWAITIO competion with an error 40 (timeout). TCPSRV does not know what to do with the -1 filenum and must dump. The CPU clock can vary from processor to processor. Therefore, machines with multiple CPUs can have widely varying clock speeds. A processor running in a CPU with a faster than average clock can have a Guardian function AWAITIOX time out earlier than expected , particularly when large time out values are being used. For the SafeTGate SSL Library this can result in returning time out to an application. Change: SafeTGate SSL Library changed to internally handle this issue. Changed the Userdef error 301 to be a fatal error to properly handle reinstate/suspend logic. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3382 TCPCLI/SSLCLI - rel3_ver0_sslc05_070202 02-FEB-07 rel3_ver0_tcpc32_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 TCPSRV/SSLSRV - rel3_ver0_ssls05_070202 rel3_ver0_tcps36_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 CTSE - rel3_ver0_ctse20_070202 TCPTPLS - $data01.n30tcpl.tcp10ps TCPTPLO - $data01.n30tcpl.tcp10po CTS - rel3^ver0^cts28^070202 CTSDC - $data01.n30cts.cts06dc CTSDDDL - $data01.n30cts.cts06ds CTSDTAL - $data01.n30cts.cts06dt CTSDTCL - $data01.n30cts.cts06da ******XPNET 3.1****************** CTS - REL3^VER1^CTS05^20070202 CTSDC - $data01.n31cts.cts04dc CTSDDDL - $data01.n31cts.cts04ds CTSDTAL - $data01.n31cts.cts04dt CTSDTCL - $data01.n31cts.cts04da Reference: Case 425545 Symptom: None. Problem: Customer needs to have the RADDR passed to the application in the XPNET message header userdata. Change: Modified to place the RADDR in the XPNET message header userdata. To specify this format, the userdata for the station must contain -R+. The default is -R-. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. In order to have the RADDR passed to the application in the XPNET message header userdata the station USERDATA must be modified to [ -R+ ]. Dependencies: CTS bound into network - rel3^ver0^cts28^070202 CTS bound into network - REL3^VER1^CTS05^20070202 TCPSRV - REL3_VER0_TCPS36_070202 TCPCLI - REL3_VER0_TCPC32_070202 SCR #3383 TCPCLI/SSLCLI - rel3_ver0_sslc05_070202 02-FEB-07 rel3_ver0_tcpc32_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 TCPSRV/SSLSRV - rel3_ver0_ssls05_070202 rel3_ver0_tcps36_070202 rel3_ver0_tcpl26_070202 rel3_ver0_ctse20_070202 CTSE - rel3_ver0_ctse20_070202 Reference: Case #429402. Symptom: Broken Socket detection time is not initiating a zero length message at proper intervals. Problem: Mastercard Guide for Detecting Broken Sockets was ambiguous in the description of inactivity on a socket. Code assumed any acitivty on the socket would reset the inactivity timer. Mastercard requires that only SEND activity reset the inactivity timer. Change: Removed the code that reset the inactivity timer when a RECV that was posted to the TCPIP process completed with data. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI, GOTCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. In order to have the Broken Socket detection enhancement function on a station the station USERDATA must be modified to [ -B+ ]. See SCR3355 for more detail on Broken Socket Detection configuration. Dependencies: None. SCR #3385 GOTCPSRV - $data01.n30tcps.gotcps08 02-FEB-07 GOTCPCLI - $data01.n30tcpc.gotcpc07 Reference: Case 426842 Symptom: TCPSRV creats multiple saveabends when trying to create the backup process. Problem: The TCPSRV is started from a TACL that is no longer running when the primary TCPSRV process goes down. The TCPSRV backup takes over then tries to create the backup. This fails because the RUN statement does not specify the IN and this is defaulted to the TACL that was running when the RUN statment was executed. This TACL no longer is running and the CRE lib tries to open it and creates saveabends. Change: Changed the RUN statement to include the IN statment. Implementation: Install new GOTCPCLI and GOTCPSRV files. Dependencies: None. SCR #3391 TCPCLI/SSLCLI - rel3_ver0_sslc06_070522 22-MAY-07 rel3_ver0_tcpc33_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 TCPSRV/SSLSRV - rel3_ver0_ssls06_070522 rel3_ver0_tcps37_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 CTSETPLS - $data01.n31ctse.ctse03ps CTSETPLO - $data01.n31ctse.ctse03po Reference: Case 426307 Symptom: The Services file is constantly being accessed by the TCPSRV/CLI process. Problem: Code only checks for blanks when deciding to make the call to GETSERVBYNAME. It should verify that the Port number contains alphbetic characters before making the call. Code also overwrites the value returned by GETSERVBYNAME actually making the call useless. Change: Removed the call to GETSERVBYNAME. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3392 TCPCLI/SSLCLI - rel3_ver0_sslc06_070522 22-MAY-07 rel3_ver0_tcpc33_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 TCPSRV/SSLSRV - rel3_ver0_ssls06_070522 rel3_ver0_tcps37_070522 rel3_ver0_tcpl27_070522 rel3_ver0_ctse21_070522 CTSETPLS - $data01.n31ctse.ctse03ps CTSETPLO - $data01.n31ctse.ctse03po GOTCPSRV - $data01.n30tcps.gotcps09 GOTCPCLI - $data01.n30tcpc.gotcpc08 Reference: Case 432456 Symptom: Enhancement for Large Remote and Local Address fields for CTS stations. Increased the number of connections the TCPSRV/CLI and SSLSRV/CLI can support. Pior maximum was 510 this was increased to 1000. Problem: None. Change: Enhancement to utilize the larger local and remote address fields for XPNET 3.1 CTS stations. The fields increase from 24 bytes to 56 bytes. Added the MAXRECVSEND param to the GOTCPSRV and GOTCPCLI obey files the default is 4095. This is number of XLCB's the process is allowed. This is increased to allow for the increased number of allowed stations per process. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3401 TCPSRV/SSLSRV - rel3_ver0_ssls07_070610 10-JUN-07 rel3_ver0_tcps38_070610 Reference: Case #435003 Symptom: An attempt to refresh the SSL Certificate with an impossible event: ATML0031 - state : 3 - AVAILABLE event : 16 - CLOSE_ALL action : 15 - NONE nextstate: 1 - IDLE ATML0031 - state : 1 - IDLE event : 20 - ACC1_COMP action : -1 - UNKNOWN_ACTION nextstate: -1 - UNKNOWN STATE ATML0031 - state : 1 - IDLE event : 14 - TCP_IMPOSS_EVT action : 14 - S_IMPOSS_EVT nextstate: 1 - IDLE see case for complete state table. Problem: The finite state machine was not handling the case were a station in the avaiable state had a CLOSE_ALL event occur. Instead of transitioning to IDLE state it should have remained in the AVAILABLE state. The ACCEPT completes in the IDLE state which is invalid. The ACCEPT should complete in the AVAILABLE state. The CLOSE_ALL event is initiated by the REFRESH of a certificate. Change: Altered the finite state machine of STARTING stations to remain in the current state when the CLOSE_ALL event occurs. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3407 TCPCLI/SSLCLI - rel3_ver0_sslc08_070713 13-JUL-07 rel3_ver0_tcpc35_070713 TCPSRV/SSLSRV - rel3_ver0_ssls08_070713 rel3_ver0_tcps39_070713 Reference: Case 437578 Symptom: TCPCLI dumps when RADDR port number is greater then 32K. Problem: The code sets the port number to a long variable. This variable is cast to a short and then moved to an unsigned short. Prior to SCR3392 this although incorrect and should have caused a dump, worked for values greater then 32K. The code was surrounded by signal calls that turned off arithmetic overflow trap. SCR3392 removed the signal calls turning arithmetic overflow trap on. Change: Corrected statement to cast the long variable to an unsigned integer before moving it to the unsigned integer variable. Implementation: Move in the new SSLSRV/CLI, TCPSRV/CLI and CTSE modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI and TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3416 TCPSRV/SSLSRV - rel3_ver0_ssls09_070928 28-SEP-07 rel3_ver0_tcps40_070928 TCPTPLS - n30tcpl.tcp11ps TCPTPLO - n30tcpl.tcp11po Reference: Case 443866 Symptom: - TCPSRV log event number 2002 does not include remote IP address. - TCPSRV log event currently looks like below: 07-09-28;16:50:35.123 \S.$P ACI.XPTCP.3000 2002 S1A^STA01 - accept_nw2() error 4120 - (ECONNRESET) Connection reset by remote host. Problem: This is a request for an enhancement. Change: Added the remote IP address to log event 2002. Implementation: Move in the new SSLSRV and TCPSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/TCPSRV. Re-start the previously stopped stations. Dependencies: None. SCR #3419 TCPCLI/SSLCLI - rel3_ver0_sslc09_071025 25-OCT-07 rel3_ver0_tcpc36_071025 rel3_ver0_tcpl29_071025 rel3_ver0_ctse22_071025 TCPSRV/SSLSRV - rel3_ver0_ssls09_070928 rel3_ver0_tcps40_070928 rel3_ver0_tcpl29_071025 rel3_ver0_ctse22_071025 CTSE - rel3_ver0_ctse22_071025 GOTCPCLI - $data01.n30tcpc.gotcpc09 TCPTPLS - n30tcpl.tcp11ps TCPTPLO - n30tcpl.tcp11po Reference: Case 443311 Symptom: None. Problem: None. Change: New release of SSLLIB. * Enhancement to allow SSL CLIENT to initialize without a Certificate. This allows an application that is always a SSL CLIENT to work without requiring a certificate. INCLUDED new SSLLIB header files and added event messages to the ctse_sslerror proc. Added a new param "CERT^IN^CONFIG" to the GOTCPCLI file. Valid values are "NO" and "YES". A value of "NO" means that there is no CERTFILE param in the SSL CONFIGURATION file. It indicates to the SSLCLI that it can run as a SSL Client without requiring a Certificate. A value of "YES" or the default, is that the SSLCLI will not initialize without the CERTFILE param in the SSL CONFIGURATION file. Implementation: Move in the new SSLCLI and SSLSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLCLI and SSLSRV. Re-start the previously stop stations. Dependencies: None. SCR #3420 TCPCLI/SSLCLI - rel3_ver0_sslc09_071025 25-OCT-07 rel3_ver0_tcpc36_071025 rel3_ver0_tcpl29_071025 rel3_ver0_ctse22_071025 TCPSRV/SSLSRV - rel3_ver0_ssls09_070928 rel3_ver0_tcps40_070928 rel3_ver0_tcpl29_071025 rel3_ver0_ctse22_071025 CTSE - rel3_ver0_ctse22_071025 Reference: Case #443716 Symptom: TCPSRV dumping multiple times Problem: In the case where the BIP connection is made and no activate bit is sent by the client side, if a message is sent from xpnet to the server the station goes SUSPENDED. If after this occurs a error such as a 4120 is detected on the socket the TCPSRV is incorrectly setting a suspend flag to false indicating that the TCPSRV now thinks the station is not suspended. If another message is sent by XPNET it is queued until the SUSPEND/REINSTATE time expires, the message is then sent to TCPSRV. TCPSRV gets this new CTS_SEND_DATA and because BIP is not activated yet tries to reply to a CTS_RECV_DATA that has not been been posted by XPNET. This causes TCPSRV to dump. Change: I have removed the code in TCPL that sets the suspend flag to FALSE on a socket error when the inactivate message has not been received by TCPL. Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stop stations. Dependencies: None. SCR #3429 TCPCLI/SSLCLI - rel3_ver0_sslc10_080415 15-APR-08 rel3_ver0_tcpc37_080415 rel3_ver0_tcpl30_080415 TCPSRV/SSLSRV - rel3_ver0_ssls10_080415 rel3_ver0_tcps41_080415 rel3_ver0_tcpl30_080415 Reference: Case #459714 Symptom: TCPCLI Userdata is set to "-D-" but TCP_NODELAY is not working. Problem: Prior fix in release TCPL19 caused the TCP_NODELAY SETSOCKOPT to not be executed. This effects TCPC26 and above and TCPS30 and above. Change: Added code in the TCPL to correctly evaluate the nodelay socket flag and execute the SETSOCKOPT for TCP_NODELAY. Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3430 TCPSRV/SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 rel3_ver0_tcps41_080415 rel3_ver0_tcpl30_080415 rel3_ver0_ctse23_080415 TCPTPLS - n30tcpl.tcp12ps TCPTPLO - n30tcpl.tcp12po TCPEC - n30tcpl.tcp10ec TCPEDDL - n30tcpl.tcp10es TCPETAL - n30tcpl.tcp10et TCPETCL - n30tcpl.tcp10ea GOTCPSRV - n30tcps.gotcps10 Reference: Case #452675 Symptom: ATM has an established connection. A network problem occurs that causes the ATM to detect that the connection is gone before the XPNET side detects that the problem has occurred. The ATM reconnects and the connection attempt is rejected. This can go on until the XPNET HP side detects the connection is broken by KEEPALIVES. The default keepalive timeframe is approximately 6 minutes. Problem: XPNET TCPIP is designed to accept the first connection and subsequent connections destine for that end point are rejected. Change: This enhancement will allow the customer to configure a TCPSRV to accept subsequent connection attempts destine for a particular end point (XPNET STATION). There is a new param in the GOTCPSRV file - LASTCONN. If LASTCONN is set to ON it will allow XPNET stations that are configured with a RADDR other then BLANKS to accept a connection when already connected. The initial connection will be torn down and this new connection will become the active connection. XPNET stations with a RADDR of BLANKS will not be affected. This enhancement should only be used in a secure network. The following TELL command will allow the LASTCONN param to be changed online. TELL EXTERNAL $PPD.#TCPALTR, "LASTCONN ON" TELL EXTERNAL $PPD.#TCPALTR, "LASTCONN OFF" Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3431 TCPSRV/SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 rel3_ver0_tcps41_080415 rel3_ver0_tcpl30_080415 rel3_ver0_ctse23_080415 TCPTPLS - n30tcpl.tcp12ps TCPTPLO - n30tcpl.tcp12po TCPEC - n30tcpl.tcp10ec TCPEDDL - n30tcpl.tcp10es TCPETAL - n30tcpl.tcp10et TCPETCL - n30tcpl.tcp10ea GOTCPSRV - n30tcps.gotcps10 Reference: Case #435617 Symptom: Round Robin Connection Enhancement. Problem: The TCP/IP server process (TCPSRV) should be configurable to allocate incoming connections to the available stations in a round-robin fashion. Currently connections are allocated to the station which was started last. Currently in a configuration of multiple resource nodes with multiple stations utilizing a TCPSRV process, if a start station * command is used to start the stations, the stations on the last resource node are started last and therefore receive the bulk of the connections. In the event of a CPU failure which results in a NETWORK process takeover, all the stations on that resource node are re-opened by the backup which therefore become the last started and consequently take all the connections. This results in potentially the least stable resource node taking the heaviest traffic load. Changing TCPSRV to allocate connections on a round-robin basis across all available stations would load balance the incoming traffic across all resource nodes. Change: This enhancement will allow the customer to configure a TCPSRV to have connections accepted by XPNET STATIONs in a round robin fashion. The first XPNET STATION started will get the first connection. Once that station is stopped it will go to the bottom of the list and will not accept a connection until all other stations have at least one connection. There is a new param in the GOTCPSRV file - RRCONN. If RRCONN is set to ON it will allow XPNET stations that are configured with a RADDR of BLANKS to be a round robin group and round robin distribution will occur within that group. Any other type of RADDR configuration that takes advantage of wildcard config will group common configs together and they will have connections distributed in a round robin fashion within that group. The following TELL command will allow the LASTCONN param to be changed online. TELL EXTERNAL $PPD.#TCPALTR, "RRCONN ON" TELL EXTERNAL $PPD.#TCPALTR, "RRCONN OFF" Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3432 SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 SSLCLI - rel3_ver0_sslc10_080415 Reference: Case #461913 Symptom: SSLSRV Abends when Certificate Refresh is issued. Problem: Finite State Machine did not take into account the possiblity that a station may be shutting down as the Refresh is issued. This puts the station in the Shutdown_pending state. In this state there is no IO to respond to XPNET with. Code dumps when Reply fails. Change: Changed the FSM to do nothing in the Shutdown_pending state if a refresh is issued. The station will continue with the shutdown. Implementation: Move in the new SSLSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI Re-start the previously stopped stations. Dependencies: None. SCR #3433 TCPSRV/SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 rel3_ver0_tcps41_080415 rel3_ver0_tcpl30_080415 Reference: Internal Symptom: None. Problem: None. Change: Enhancement to allow wildcarded IP addresses to include a wildcarded Port number. Prior to this enhancement the following configuration was valid: 3333:172.21.200.* or 3333:172.21.*.*. The port had to be static. This enhancement will allow the following: 0:172.21.200.* or 0:172.21.*.*. Implementation: Move in the new SSLSRV and TCPSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV or TCPSRV. Re-start the previously stopped stations. Dependencies: None. SCR #3434 SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 SSLCLI - rel3_ver0_sslc10_080415 STGKM - $data01.u10ssll1.stgk05 T0000D48_03_STGKM_20MAR2008_V1R1 Reference: Case 438351 Symptom: The following sequence would result in an ABEND in SafeTGate SSL Library (specifically, at #ssl_process_vsocket_send_complete). - Application issues SEND_NW or SEND_NW2 on an SafeTGate SSL Library encrypted socket. - The socket is cleaned up (closed) before the send operation completes. - Another SEND_NW/2 operation is issued on a different socket before the prior send completes. - 1st send completes without error. - 2nd send completes. Problem: The buffer used for a pending SEND_NW operation was being released when a socket was cleaned up. If that buffer was reused by another socket before the SEND_NW operation completed, the (eventual) SEND_NW completion could be treated as belonging to the new socket. This would corrupt a linked list of send buffers. Change: New release of SSLLIB. Implementation: Move in the new SSLSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI. Re-start the previously stopped stations. Move in the new STGKM module. Dependencies: None SCR #3435 TCPSRV/SSLSRV - rel3_ver0_ssls10_080415 15-APR-08 rel3_ver0_tcps41_080415 Reference: Internal Symptom: None. Problem: None. Change: Added code to allow the TIMEOUT param to be set to a -1 value. This value will allow an ACCPET to always be posted and no timers set when a connection is rejected. The connection will be rejected immediately. Also added the following command to allow the Param TIMEOUT value to be changed on line. TELL EXTERNAL $PPD.#TCPALTR, "TIMEOUT val" Implementation: Move in the new SSLSRV and TCPSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV or TCPSRV. Re-start the previously stopped stations. Dependencies: None SCR #3452 TCPSRV/SSLSRV - rel3_ver0_ssls11_080915 15-SEP-08 rel3_ver0_tcps42_080915 Reference: Case #476202 Symptom: TCPSRV dumps. Problem: If the LAST CONN option is being used it is possible that the TCPSRV can reply an XPNET CTS RECV with an invalid tag number causing TCPSRV to dump. Change: When using LAST CONN and a connection attempt comes into TCPSRV that matches a server stations configured RADDR the code moves the control block ctsi recvinfo message tag into the recv tag field. The code then replies to XPNET with that tag. The control block ctsi recvinfo message tag is the saved tag number from the last IO. In the chance that the LAST CONN accept completes after an IO is posted that is not a RECV this non recv tag could get moved into the reply tag and cause the dump. Added code to reply to the XPNET RECV when a LAST CONN accept completes without moving the control block ctsi recvinfo message tag into the recv_tag field. The recv tag will contain the recv tag from the last recv IO. Implementation: Move in the new SSLSRV and TCPSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV or TCPSRV. Re-start the previously stop stations. Dependencies: None. SCR #3458 SSLSRV - rel3_ver0_ssls12_081215 15-DEC-08 Reference: Case #480141 Symptom: TCPSRV dumps when using LASTCONN. Problem: When an ACCEPT CONN is posted to TCPSRV it searches a linked list of outstanding ACCEPTS that have completed from the TCPIP process. If one matches the RADDR of the ACCEPT CONN from XPNET the outstanding ACCEPT is deleted from the linked list. The code incorrectly returned out of the search even if it did not find a match with an address. This address signaled the calling proc to free up the returned memory. This memory was actually still linked into the linked list. When the linked list was accessed again the search tried to free up the memory that was already freed causing TCPSRV to dump. Change: Changed code to only return an address when a match was found. Implementation: Move in the new SSLSRV and TCPSRV modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV or TCPSRV. Re-start the previously stop stations. Dependencies: None. SCR #3465 SSLSRV - rel3_ver0_ssls12_081215 15-DEC-08 SSLCLI - rel3_ver0_sslc11_081215 Reference: Case #478173 Symptom: SSL stations go abnormal when any SSL error is reported. Problem: The issue here is that the SSLSRV/CLI code looks at any return code from the SSLLIB other then INS_SSL_RC_OK as a fatal error and the station is sent to the ABNORMAL state. In this case the error INS_SSL_RC_AL_CERTIFICATE_UNKNOWN is sending the station to ABNORMAL. The customer questioned whether in a POS enviroment an error such as this could be sent back to STARTING so that the station could be available for another viable Client. Change: Added code to allow a new param SSL^ERR^ACT to indicate whether SSL errors will be handled as either fatal errors or retryable errors. This param will take affect after a succsseful startup of the SSLSRV/CLI process. Any SSL errors during startup will be considered FATAL. New go file startup param: SSL^ERR^ACT - values - RETRY or FATAL. New TELL commands: NCPCOM> TELL EXTERNAL $SRV.#SSLALTR,"SSLERRACT RETRY" NCPCOM> TELL EXTERNAL $SRV.#SSLALTR,"SSLERRACT FATAL" NCPCOM> TELL EXTERNAL $CLI.#SSLALTR,"SSLERRACT RETRY" NCPCOM> TELL EXTERNAL $CLI.#SSLALTR,"SSLERRACT FATAL" Implementation: Move in the new GOTCPSRV and GOTCPCLI macros and set the new param as required. Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Install the new TCPTPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3467 SSLSRV - rel3_ver0_ssls12_081215 15-DEC-08 SSLCLI - rel3_ver0_sslc11_081215 Reference: Case #484415 Symptom: TCPSRV Dumps. Problem: Ten years ago a fix was placed into the CTSE part of the TCPSRV/SSLSRV. This fixed added the #pragma nostdfiles which instructs the CRE run time library to omit opening the standard streams. This requires CTS/E to explicitly open whichever streams are needed using the fopen_std_file function. This fix missed the printf statements in the TCPSRV/SSLSRV TCPLIBs. The printf statement that caused this dump is used when the Primary log file and Alt log file are unavailable to log a message. A printf statement in CTSE was missing an argument. Found during testing this caused a dump. Change: Added the OPEN_STDOUT_D to open the standard out and added the define CLOSE_STDOUT_D to close standard out when a printf statement is executed. Added the argument for the printf statement in CTSE. Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3466 SSLSRV - rel3_ver0_ssls13_090110 10-JAN-09 SSLCLI - rel3_ver0_sslc12_090110 Reference: Internal. Symptom: Link fails because server doesn't accept the protocol version (3.2) offered in the client hello handshake message. Problem: SafeTGate SSL Library didn't have the support for the TLS version 1.1. Change: Support for the TLS protocol version 1.1 is added to the SafeTGate SSL Library. Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3482 SSLSRV - REL3_VER0_SSLS14_090320 SSLCLI - REL3_VER0_SSLC13_090320 20-MAR-09 Reference: case #491524 Symptom: SSLSRV/CLI shuts down connections when a Certificate refresh is done. Problem: Original code design was to shut down the connection when a Certificate refresh was done. Change: Removed the code that performed the connection shut down when a Certificate Refresh is done. Implementation: Move in the new SSLSRV and SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV and or SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3483 TCPSRV/SSLSRV - rel3_ver0_ssls15_090330 09-MAR-30 rel3_ver0_tcps44_090330 TCPCLI/SSLCLI - rel3_ver0_sslc14_090330 rel3_ver0_tcpc39_009330 Reference: Case #492742 Symptom: TCPSRV Abends. Problem: A BIP station on start up sends (BSTUNINIT) an active bit. The send is in the JUST_CONNECTED state of the FSM. Before the SEND completed back to the TCPSRV a CTS_RECV was received by the TCPSRV. This put the TCPSRV FSM into the RECV_PEND state. The RECV_PEND state was coded go to the WAIT_DEALLOC state when a BSTUNINIT send completed. While in the WAIT_DEALLOC state a CTS_SEND data was received from XPNET. When in the WAIT_DEALLOC state a CTS_SEND will cause the TCPSRV to reply to the CTS_SEND with a NO_CONN error. The NO_CONN error causes XPNET to send a CTS_SUSPend to TCPSRV. TCPSRV replies correctly to the CTS_SUSP over the CTS_RECV IO that had been posted by XPNET. XPNET now has no RECV posted to TCPSRV. TCPSRV receives the ACTIVE BIT and tries to reply to XPNET with an invalid tag. Change: Changed the FSM so that when TCPSRV/CLI is in the RECV_PEND state and a BSTUNINIT completes the FSM remains in the RECV_PEND state. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3497 TCPSRV/SSLSRV - REL3_VER0_SSLS16_090715 09-JUL-15 REL3_VER0_TCPS45_090715 REL3_VER0_TCPL33_090715 TCPCLI/SSLCLI - REL3_VER0_SSLC15_090715 REL3_VER0_TCPC40_090715 REL3_VER0_TCPL33_090715 Reference: Case #500266 Symptom: - TCPSRV dumps. - issue on Tcp/ip For WinEpts device Problem: Station is configured with the following userdata: "-5,L5,F5,TA,PB5A00000 -K+" TCPSRV incorrectly receives five bytes of ASCII 0's "00000". The TCPLIB code does not take into account the length of the PB (PAD BACK) when determining the MIN length of the first step of the two step read to get the entire length indicator. Because of the F5 factor in the length indicator the code thinks that the MIN of the first read is 5. When determining the position in the read buffer the code uses the actual length of the entire length indicator including the Back Pad. This causes the code to pass on an invalid length of what was read, in this case it passes -5 to a memcpy call forcing the dump. In this case because the message received was invalid the code should not dump but should log a message and shutdown the socket. Change: Include the length of the BPAD in the calculation of the MIN length when reading the first step of the two step read. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3503 TCPSRV/SSLSRV - REL3_VER0_SSLS16_090715 15-JUL-09 REL3_VER0_TCPS45_090715 REL3_VER0_TCPL33_090715 TCPCLI/SSLCLI - REL3_VER0_SSLC15_090715 REL3_VER0_TCPC40_090715 REL3_VER0_TCPL33_090715 Reference: case #503852 Symptom: - TCP/IP server stations are going into abnormal state when a client tries to connect and a timeout occurs. - Error 4126 (ETIMEDOUT) occurs on accept_nw2. - Log Messages: 09-17-16;10:10:18.720 \SYS.$P1TS ACI.XPTCP.3000 2002 S1A^01 - accept_nw2() error 4126 - (ETIMEDOUT) Connection timed out - ADDR - 2345:11.222.333.44. 09-17-16;10:10:18.726 \SYS.$P1AN ACI.XPNET.3100 6290 CTS request error 5 (connection request rejected) for station S1A^01 on line L1A^01, request ACCEPT_CONN CTS subsystem error 4126 (4126), operator intervention required. 09-17-16;10:10:18.728 \SYS.$P1AN ACI.XPNET.3100 2105 Station S1A^01 on Line L1A^01 closed because of a fatal CTS error - connection request rejected on req ACCEPT_CONN, detail 4126, station will remain closed. Previous STARTING, Current ABNORMAL Problem: Error 4126 to accept_nw2 is treated as a fatal error causing the station to go into the abnormal state. Change: Make accept_nw2 error 4126 (ETIMEOUT) a retryable error. This allows the station to go back into the starting state if station retries and/or station error action is configured to do so. Implementation: Stop all lines/station using the TCPSRV process, stop the TCPSRV process, install new TCPSRV object, restart TCPSRV, and restart the lines/stations. If running on a RISC machine, execute the TCPAXCL file. Rebuild template files on the scribe subvolume as normal (see TMPLMAKE and GOINST). Dependencies: None SCR #3505 TCPSRV/SSLSRV - REL3_VER0_SSLS16_090715 09-AUG-14 REL3_VER0_TCPS45_090715 REL3_VER0_TCPL33_090715 TCPCLI/SSLCLI - REL3_VER0_SSLC15_090715 REL3_VER0_TCPC40_090715 REL3_VER0_TCPL33_090715 Reference: Internal RFE Symptom: - New requirement to handle a message SUFFIX. - Strip and add a SUFFIX to the TCP message without impact to the XPNET application process. - Handle one very specific "leased line" message format as documented on page 1 of the "FDMS RISC/6000 Implementation of TCP/IP" version 1.3 document dated 10/21/04. Problem: No problem. This is an enhancement. Change: Modified the "-5" userdata format to allow specification of a message SUFFIX. This SUFFIX will be added to the end of outbound messages and stripped from the end of incoming ones. The general syntax and handling is the same as for "pad front" (pf) and "pad back" (pb) except the new specifier (s or S) is used to designate a SUFFIX. As stated in the "NET24-XPNET TCP/IP Protocol Implementation Guide" (XN-PL300-03), the CTSE userdata field has a limit of 63 bytes; that limit has not changed. The number of bytes of SUFFIX is limited by the total number of bytes used by the other parts of the -5 configuration up to 63 bytes. A userdata example for the FDMS message described above follows. Note the "s4" which specifies a 4 byte SUFFIX. "-5,pf4%h02%h46%h44%h02,l2,tb,f0,s4%h03%h46%h44%h03" Note: While changing the parsing of -5 userdata, two problems were found and corrected. 1) "PF" was properly identified as pad front, but "Px" (where x is anything other than "F" or "B") was improperly identified as pad back. Changed the parsing to accept "PF" and "PB" only. 2) Valid value types are "A", "E", and "%H". Some old code that attempted to handle type "B" had not been removed, and could cause unpredictable results. That old code was removed. For example, "-5,pf3B123" is invalid and should now be rejected. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3506 SSLSRV - REL3_VER0_SSLS16_090715 09-JUL-15 SSLCLI - REL3_VER0_SSLC15_090715 SSLLIB - T0000G06_13_STGSSLLIB_12AUG2009_V1R1_SPCL Reference: Internal. Symptom: None. Problem: None. Change: New release of SSLLIB bound into SSLSRV/CLI supports following NEW PARAMS in the SSLCONFIG file. Please see the latest version (March 09) of the "SafeTGate SSL Library Guide". · SERVERMINPROTVERSION: specifies the lowest version of SSL that will be accepted from an incoming client connection Possible values are SSL30, TLS10 and TLS11, and the default is SSL30. · CLIENTMINPROTVERSION: specifies the lowest version of SSL that will be accepted for an outgoing client connection Possible values are SSL30, TLS10 and TLS11, and the default is TLS11. · CLIENTHELLOPROTVERSION: specifies the version of SSL that is specified in the SSL "client hello". This parameter may be needed for those SSL server implementations that don't support TLS 1.1 and reject the connection if this option is presented in the "client hello" Possible values are SSL30, TLS10 and TLS11, and the default is the current value of CLIENTMINPROTVERSION. · ALLOWMD5SIGNATURES: specifies if certificates with a signature based on an MD5 hash will be accepted during certificate authentication and verification. It is recommended that this is left to the default value of NO, in order to protect against the recently published MD5 based signature vulnerability when used with PKI. The default is NO. **** NOTE: * Impact due to new release of SSLLIB that is bound into SSLSRV/CLI. * MD5 Hash Based Digital Signature Support Due to security vulnerabilities associated with digital signatures based on MD5 hashes, X.509 certificates with MD5 based digital signatures will no longer be supported by default. Although not recommended, if you wish to continue to support these signatures, set the ALLOWMD5SIGNATURES in the SSLCONFIG file to YES; this allows for continued support of MD5 based signatures. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3509 TCPSRV/SSLSRV - REL3_VER0_SSLS17_091019 19-OCT-09 REL3_VER0_TCPS46_091019 TCPCLI/SSLCLI - REL3_VER0_SSLC16_091019 REL3_VER0_TCPC41_091019 Reference: 1012846 Symptom: - TCPCLI, SSLCLI, TCPSRV, or SSLSRV abend with tcp_fsm and ctse_stop at the top of the stack. Problem: A message with a bad length was received while in the suspended state. Event "e_0_recv_comp_bad_lgth" was not allowed for in state "suspended". Change: Allow for event "e_0_recv_comp_bad_lgth" in the "suspended" state. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3515 TCPSRV/SSLSRV - REL3_VER0_SSLS17_091019 15-DEC-09 REL3_VER0_TCPS46_091019 Reference: Case #925818 Symptom: Error in EMS after CPU Failure - An Accept_NW2 error 60 occurs hours after the CPU take over and the stations go abnormal. Problem: The code treats the Accept_nw2 error 60 as a fatal error. Change: Altered the code to treat the Accept_NW2 as a retryable error. The existing socket will be torn down, a new socket will be created after the station transitions back to the starting state. The station will then be available as an endpoint for new connections. Implementation: Bring down the existing TCPSRV/SSLSRV process. Move in the new TCPSRV/SSLSRV modules. See implementation guide for configuration along with above info. Re-start TCPSRV/SSLSRV. Re-start corresponding stations. Dependencies: None. SCR #3516 SSLSRV - REL3_VER0_SSLS17_091019 17-DEC-09 SSLCLI - REL3_VER0_SSLC16_091019 SSLLIB - T0000D48_03_STGSSL10DEC20092009__SPCLV1R1 Reference: Case 01015668 Symptom: SSLSRV or SSLCLI abend. Problem: Arithmetic error in cryptographic routines. Change: New release of SSLLIB bound into SSLSRV/CLI. The new SSLLIB was created to correct an abend caused by a SSL key exchange handshake message that triggered an arithmetic error in the cryptographic routines. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None SCR #3528 GOTCPSRV - n30tcps.gotcps12 30-JUN-10 GOTCPCLI - n30tcpc.gotcpc11 Reference: Case #1082075 Symptom: None. Problem: Update comments to make the DNS defines clear. Change: Updated comments for the DNS Defines. =tcpip^host^file =tcpip^resolver^name Implementation: Move in the new GOTCPSRV and GOTCPCLI macros and set the new param as required. Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Dependencies: None. SCR #3530 TCPSRV/SSLSRV - REL3_VER0_SSLS19_100815 15-AUG-10 REL3_VER0_TCPS48_100815 TCPCLI/SSLCLI - REL3_VER0_SSLC18_100815 REL3_VER0_TCPC43_100815 TCPTPLO - $data01.n30tcpl.tcpl15o TCPTPLS - $data01.n30tcpl.tcpl15s Reference: Case #1085901 Symptom: SSLSRV code goes into a looping condition. Problem: SCR3525 did not handle the situation where a SSLSRV station that was STOPPED or ABORTED and then STARTED again and a rougue connection was accepted. SCR3525 created a condition where the last member of an internal linked list NEXT pointer was not updated which caused the NEXT pointer to point to the head of the list. When a rouge connection was accepted and not found on the list the code would then go into the loop condition. Change: Replaced code involved with SCR3525 with code that preforms a INS_SSL_SHUTDOWN_NW() on any socket that had an INS_SSL_ACCEPT2_NW() posted or had a INS_SSL_ACCEPT2_NW() complete on it when an ABORT command was issued. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Install the new TCPTPLO file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3546 TCPSRV/SSLSRV - REL3_VER0_SSLS20_110130 30-JAN-11 REL3_VER0_TCPS49_110130 Reference: Case #1087457 & #1104279 Symptom: - Hours after a CPU dump and an error 211 reported by the TCPSRV process the following log messages are seen. 10-11-23;11:19:37.157 \PROD.$ASIT1 ACI.XPTCP.3000 2002 S1E^N50DIAL164 - accept_nw2() error 60 - The file resides on a removed volume, the device is downed or not open, or a server has failed and a process has been replaced by a different process with the same name since the server was opened. 10-11-23;11:19:37.161 \PROD.$Q1EN ACI.XPNET.3100 6289 CTS request error 10 (file system error encountered by CTS/E) for station S1E^N50DIAL164 on line L1E^N50DIAL164, request ACCEPT_CONN, Guardian error 60 (60), operator intervention required. Problem: When XPNET TCPIP server stations are in the STARTING state, the TCPSRV process has an open (SOCKET) posted to the HP TCPIP process associated with that Station. When a CPU fails containing the HP TCPIP stack the opens(SOCKETS) are not cleaned up from the TCPSRV perspective. These opens where done on the Primary HP TCPIP Stack and after the CPU failure the backup takes over. When a connection is accepted by the TCPSRV process it then posts an ACCEPT_NW2() on the open (SOCKET) on behalf of the XPNET station in the STARTING state. The new primary HP TCPIP Stack fails the ACCEPT_NW2() with an error 60 because it does not know about the open (SOCKET). The reason the HP TCPIP Stack does not know about the open is because the HP TCPIP Stack is not coded to do checkpointing. Change: When the TCPSRV process detects an ACCEPT_NW() completing with an error 211 - CPUDOWN. The TCPSRV process will close all stations that are in the STARTING state. Stations in the STARTED will be handled by the completion of the RECV_NW()s that are posted to the HP TCPIP process. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3543 SSLSRV - REL3_VER0_SSLS21_110715 01-SEP-11 SSLCLI - REL3_VER0_SSLC19_110715 SSLLIB - T0000D48_03_STGSSLLIB_12AUG2011_V5R0 1) Reference: Case #1101863 Symptom: - SSLSRV Dumps. Problem: SSLLIB returns from INSESSION_AWAITIOX() with a filenum that no longer is in use. A susequent call to GET_FILEINFO() causes the SSLSRV to dump. Change: If the CONNECTIONTIMEOUT expires without recv_nw posted by an application, SSL Library wouldn't queue the completion code properly, resulting in the connection not being cleaned up properly when recv_nw eventually gets issued, and even abend if send_nw gets called instead. Fixed. (11090930 090930-CR60) 2) Reference: Case #1132341 Symptom: A server process using the SafeTGate SSL Library abends when a client attempts to renegotiate existing connection after the certificate refresh has been performed. Problem: Library was attempting to use the old certificate that has been removed. Change: SafeTGate SSL Library fixed to properly handle the scenario. Dependencies: None. (11100930 100930-CR139) 3) Reference: Case #01135691 Symptom: Process abends - unable to allocate memory. Problem: Memory leak caused by improper increment to session reference count when Client requests SSL session renegotiation. Change: Ensure reference count is not incremented when client requests SSL session renegotiations SSL session. Dependencies: None. (11110706 110731-CR216) 4) Reference: Internal. Symptom: A server process using the SafeTGate SSL Library abends while trying to process client key exchange message during the handshake. Problem: In some rare circumstances, core library for large integer arithmetics produces an error that causes the process to abend. Change: SafeTGate SSL Library changed to internally handle this issue. (11100331 090930-CR77) 5) Reference: Internal. Symptom: A client process using the SafeTGate SSL Library is not attempting to reuse existing sessions with the known server when configured to do so. This results in extensive memory consumption when there are lots of connection attempts to the same server. Problem: Faulty code for session reuse on the client side. Change: SafeTGate SSL Library fixed to properly reuse the existing sessions. Dependencies: None. (11100930 100930-CR136) 6) Reference: Internal. Symptom: A process using the SafeTGate SSL Library aborts the renegotiation attempt's handshake after receiving the finished message from the peer, when the renegotiated connection used the TLS 1.1 protocol version. Problem: Library wasn't changing the cipher state because of the change cipher state message being ignored. Change: SafeTGate SSL Library fixed to properly handle the scenario. (11100930 100930-CR150) * New SSLLIB version release: $DATA01.U10SSLL1.SSLL16 GMT Binder timestamp: 08JUL2011 06:13:28 Version procedure: T0000D48_03_STGSSLLIB_06JUL2010_V1R1 Version procedure: T0000D48_03_DSXLALIB_30SEP2010_V4R2 Version procedure: T0000D48_03_ICAPLIB_30SEP2010_V4R2 Version procedure: T0000D48_03_CSEVENTLIB_30SEP2010_V4R2 Version procedure: T0000D48_03_PRODUCTIA_30SEP2010_V4R2 Native Mode: Not runnable file 7) Reference: Case #01156470 Symmptom: Various undeserved decode errors on connections, even possible ABEND Problem: TCPIP proocess delivers messages sent to socket that had connection timeout to another socket. Change: Issue internal shutdown_nw after the connection timeout. Dependencies: None. (50110812 110812-CR220) 8) Reference: Case #01102894 Symptom: SSLSRV Dump with 100930 SSLLIB Problem: Attempt to fix case #01107255 Change: Change backed out. Dependencies: None. (50110812 110812-CR164) 9) Reference: Case #01107255 Symptom: SSLSRV stuck in SEND_PENDING state Problem: SEND_NW sometimes not being completed by the library when STOP STATI ON command is issued on XPNET station Change: ins_ssl_ssl_shutdown_nw() processing improved to ensure all send_nw() operations from application receive a reply Dependencies: None. (50110812 110812-CR183) * Newest SSLLIB version release: $DATA01.U10SSLL1.SSLL17 GMT Binder timestamp: 15AUG2011 01:08:21 Version procedure: T0000G06_13_STGSSLLIB_12AUG2011_V5R0 Version procedure: T0000G06_13_DSXLALIB_12AUG2011_V5R0 Version procedure: T0000G06_13_ICAPLIB_12AUG2011_V5R0 Version procedure: T0000G06_13_CSEVENTLIB_12AUG2011_V5R0 Version procedure: T0000G06_13_PRODUCTIA_12AUG2011_V5R0 Native Mode: Not runnable file Implementation: Move in the new SSLSRV and or SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV and or SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3578 TCPSRV/SSLSRV - REL3_VER0_SSLS22_120430 30-APR-12 REL3_VER0_TCPS51_120430 TCPCLI/SSLCLI - REL3_VER0_SSLC20_120430 REL3_VER0_TCPC45_120430 Reference: Case #1197970 Symptom: - CTS external process reported invalid value for attribute STATION USERDATA. Station goes ABNORMAL. Problem: The buffer used for Userdata is only 64 bytes long. When using the -5 option this length can easily be exceeded as in this case. Initially the CTS\I code uses the configured station userdata seen in an INFO station detail from NCPCOM when starting the connection. This allows the initial attempt to succeed. Once the initial connection attempt is made the CTS/E will send back to CTS/I userdata with the default values. This is what is used in subsequent connection attempts. As stated above If using the -5 options, it is possible that the defaults along with the -5 information exceed the 64 bytes. This string is passed back to CTS/E from CTS\I and in this case the default of "BT1" is truncated at the 64 byte limit, it should have been "BT10-". The CTS\E code detects a invalid configuration and handles as an error condition. The string passed back from CTS\E is only supposed to be used for display in the status station detail in XPNET 3.1. In Xpnet 3.0 this information is displayed in the info station detail. In either case the code was overwriting the memory copy of the information from the NEF with this string. Change: Altered the TCPL routines that handle the UDATA information to determine what was passed up from CTS\I and save that information, then add any default values that will fit in the remaining space upto 64 bytes. The information passed up from CTS\I plus the added default information will be passed back to CTS\I for display in the XPNET 3.0 info station ,detail command and in the status station ,detail command in XPNET 3.1. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3589 TCPSRV/SSLSRV - rel3_ver0_ssls23_120915 15-SEP-12 rel3_ver0_tcps52_120915 TCPCLI/SSLCLI - rel3_ver0_sslc32_120915 rel3_ver0_tcpc46_120915 rel3_ver0_tcpl39_120915 rel3_ver0_ctse26_120915 CTSE - rel3_ver0_ctse26_120915 CTSEPLS - n30ctse.ctse09ps CTSEPLO - n30ctse.ctse09po CTSEEC - n30ctse.ctse05ec CTSEEDDL - n30ctse.ctse05es CTSEETAL - n30ctse.ctse05et CTSEETCL - n30ctse.ctse05ea Reference: Case #1222522 Symptom: An XPNET node running on one HP node opens a port ( TCPSRV process ) running on a different HP node. Due to an Expand failure XPNET reports an error 249 which causes the station to recycle and transition back to the STARTING state, however, the corresponding remote TCPSRV->ATM TCPIP connection is still viable. Problem: When XPNET generates the error 249 EMS event on a station it can be assumed that the TCPSRV and XPNET are out of sync in regards to the XPNET open file number and the openers table in the TCPSRV. This is a result of the Expand error 249. Xpnet receives the 249 for each IO pending to the TCPSRV process. This causes XPNET to recycle the station causing a new open being sent (successfully) to the TCPSRV over expand. TCPSRV does not know about the Expand problem (it does not have an open to XPNET it just replies to XPNET). TCPSRV retains the already established connection to the ATM and will remain in this state until either the ATM does a shutdown of the connection or the TCPSRV is recycled. Communication to TCPSRV for this channel (XPNET open filenum - TCPSRV openers table - TCPIP connection ) is broken. If the XPNET station transitions from the STARTED state to STARTING, via the error 249 a new open (this will be a different filenum then the original open that the 249 was reported on) will occur and a new ACCEPT_CONN IO will be posted to the TCPSRV. In the case of ATM's and a configured RADDR this station will remain in starting because the ATM and TCPSRV still believes original connection is viable. Change: In order to control this situation a new Tell command has been implemented. This command must be issued from an NCPCOM on the same HP node that the TCPSRV is running. The Tell command will contain the HP node name and ppd name of the remote XPNET process that is associated with the Station (channel) that is in the out of sync condition. The command will also contain the symbolic name of the station. With this information the TCPSRV process will search the openers table, match on the Pri-Handle and station name then close the tcpip connection, reply to any outstanding IO's and initialize the opener table entry. This will allow the ATM to reconnect and will acquire the XPNET station that transitioned from STARTED to STARTING via the error 249 and opened the TCPSRV with a posting of an ACCEPT_CONN. ---------------------------------------------- *** New TELL command and Log Message Ex: NCPCOM> TELL EXTERNAL $SRV.#TCPRSET,"\XXXX.$P1AN S1A^SRX000" 12-09-05;17:14:02.908 \XXXX.$SRV ACI.XPCTSE.3000 1025 TELL TCPRSET COMMAND - STA (S1A^SRX000) STA NOT FOUND. NCPCOM> TELL EXTERNAL $SRV.#TCPRSET,"\XXXX.$P1AN S1A^SRV000" 12-09-05;17:12:23.841 \XXXX.$SRV ACI.XPCTSE.3000 1026 TELL TCPRSET COMMAND - STA (S1A^SRV000) STA RESET. ----------------------------------------------- Implementation: Move in the new SSLSRV/CLI and TCPSRV/CLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start SSLSRV/CLI or TCPSRV/CLI. Re-start the previously stopped stations. Install the new CTSEPLS file re-build the EMSNRES and EMSRES template files using the GOINST obey file. Dependencies: None. SCR #3586 TCPSRV/SSLSRV - REL3_VER0_SSLS24_120830 30-AUG-12 REL3_VER0_TCPS53_120830 TCPCLI/SSLCLI - REL3_VER0_SSLC22_120830 REL3_VER0_TCPC47_120830 TCPTPLS - n30tcpl.tcp16ps TCPTPLO - n30tcpl.tcp16po Reference: Symptom: None. Problem: None. Change: Added code to support the request for a Socket Probing facility. This enhancement will send probe requests at configurable intervals. It will also respond to probe requests with a probe response. If a configured number of probe requests are unanswered or no text level messages are received from the session partner the code will ISOLATE the connection. ISOLATE will mean that XPNET will enter Suspend and Reinstate logic for the associated station. If a probe response or a text level message is received prior to the Maximum number of unanswered probes, the station will be reinstated. If the number of probe requests unanswered and no text level messages received surpasses the Maximum number of probes, the TCPSRV/CLI will disconnect the station. Params in the TCPSRV and TCPCLI startup files are Global to the running process. Tell commands can be used to override Global params on line. Station userdata configuration can be used to override any Global param for the indivdual station. Go file params: param PROBETIMER 10 - 1500 ticks. param MAXMISSEDPROBES 1 - 99 param ISOLATEMISSEDPROBES 1 - 99 param SOCKETPROBING ON/OFF/MON If SOCKETPROBING is not set the TCPSRV/CLI code will behave as if there is no probe enhancement. If SOCKETPROBING is set OFF the TCPSRV/CLI code will be aware that if a probe request is received the Node and Switch are in different modes and log a message. If SOCKETPROBING is set ON the TCPSRV/CLI code will set remaining parameters as the default for all connections in the process and all connections will use Probes unless overridden in USERDATA. If SOCKETPROBING is set to MON the TCPSRV/CLI code will set remaining parameters as the default for all connections in the process and all connections will run as Probe Monitor unless overridden in USERDATA. Probe Monitor will detect all the conditions PROBEON will detect and log messages to indicate when the Probe limits are exceeded. No other action will be taken. The above defaults can be altered on line by TELL commands. The following are examples: NCPCOM> TELL external $ppd.#TCPALTR, "PROBE ON" NCPCOM> TELL external $ppd.#TCPALTR, "PROBE OFF" NCPCOM> TELL external $ppd.#TCPALTR, "PROBE MON" NCPCOM> TELL external $ppd.#TCPALTR, "PROBE UNAWARE" NCPCOM> TELL external $ppd.#TCPALTR, "PROBETIMER 1000" NCPCOM> TELL external $ppd.#TCPALTR, "MAXMISSEDPROBES 8" NCPCOM> TELL external $ppd.#TCPALTR, "ISOLATEMISSEDPROBES 7" The following TELL command will give the default config: NCPCOM> TELL external $ppd.#TCPSTAT, "ALL" These prior defaults can be overridden at a station level by setting Station Userdata. If the startup params are not set in the start file, Station USERDATA can be used to configure each individual stations Probe settings. Station USERDATA: The following Length Indicator value must be used in order for the socket probing to work. USERDATA [ -5,l2,tb,pf2%h00%h00 ] In addition to the above USERDATA Length indicator value the following will control the Probe settings: [ -P or -p ] will indicate that the following characters are Probe descriptors and that the connection is Probe aware. [ S or s ] will use the following to indicate Probe state: 1 - PROBEON 2 - PROBEMON 3 - PROBEOFF default is - PROBEOFF [ T or t ] will indicate the timer value: Range: 10 - 1500 ticks. default is 100 ticks - 1 second. [ M or m ] will indicate the MAX-MISSED-PROBES: Range: 1 - 99. Default is 10. [ I or i ] will indicate the ISOLATE-MISSED-PROBES: Range: 1 - 99. Default is 5. Examples: USERDATA [ -5,l2,tb,pf2%h00%h00 -ps1t1400 ] The above sets the Length indicator for Probes. The -ps1t1400 indicates that the connection is probe aware and the s1 indicates PROBEON with a probe timer of 1400 ticks - 14 seconds. All other params are defaults. USERDATA [ -5,l2,tb,pf2%h00%h00 -ps3 ] The above sets the Length indicator for Probes. The -ps3 indicates that the connection is probe aware. The s3 indicates PROBEOFF (if a probe is received a log message will indicate the Node and switch are out of sync). All other params are defaults. USERDATA [ -5,l2,tb,pf2%h00%h00 -ps2I7m8 ] The above sets the Length indicator for Probes. The -ps2I7m8 indicates that the connection is probe aware and the s2 indicates PROBEMON. In monitor mode log messages will indicate when thresholds have been exceeded, no action will be taken to ISOLATE or disconnect. The MAX-MISSED-PROBES will be set to 8 and the ISOLATE-MISSED-PROBES will be set to 7. Timer is set to the default. For New log messages please see the TCPTPLS file supplied with this enhancement. ** Other XPNET Station Settings: At the XPNET Station level the ERRORACT attribute needs to be set to REINEVERY in order to take advantage of the ISOLATE functionality of the Probe enhancement. The REINSTATE value needs to be carefully selected in order to be compatible with the PROBE enhancement. Once the station is ISOLATED Suspend/Reinstate logic is enabled. The state of the connection (ISOLATED or not) will be checked each REINSTATE number of seconds. If the REINSTATE value is to large it is possible that a connection that had been ISOLATED and then received a Probe Response will sit in the suspended state for more time then necessary. If a value to low is selected it could impact performance. ** XPNET processing note: When entering the Isolated state( XPNET Suspened State ) XPNET will send a 9512 message to the process. When the REINSTATE interval is reached XPNET will attempt to reinstate the station. This means a 9513 message is sent to the process, the XPNET station will transition from SUSPENDED to STARTED and check the TCPSRV/CLI for the status of the connection. If the connection is still Isolated XPNET will send a 9512 back to the process and the station will transition back to SUSPENDED. If the connection exceeds the MAXMISSEDPROBES value then XPNET will send a 9519 message to the process and tr transition the station to STARTING and close the connection. When the connection is Isolated and the REINSTATE interval is reached XPNET will check the TCPSRV/CLI for the status of the connection. This means a 9513 message is sent to the process, the XPNET station will transition from SUSPENDED to STARTED. If a message or a Probe Response has been recieved from the connection partner the station will remain STARTED and a 9513 message is sent to the process. Implementation: Move in the new TCPSRV/SSLSRV and TCPCLI/ SSLCLI modules. Stop any of the associated stations. See implementation guide for configuration along with above info. Stop and re-start TCPSRV/SSLSRV and or TCPCLI/SSLCLI. Re-start the previously stopped stations. Dependencies: None. SCR #3623 TCPCLI/SSLCLI - rel3_ver0_sslc24_140215 15-FEB-14 - rel3_ver0_tcpc49_140215 - rel3_ver0_tcpl41_140215 TCPSRV/SSLSRV - rel3_ver0_ssls26_140215 - rel3_ver0_tcps55_140215 - rel3_ver0_tcpl41_140215 SSLLIBI - U10ssl21.SSL204 Reference: Internal Symptom: SSL security vulnerability. Change: Recompiled with new SSLLIB. Implementation: Move in the new SSLCLI/SSLSRV modules. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously stopped stations. XPNET 3.2 - move the new SSLLIBI to the XPNET subvol and rerun the NETBC obey file to build a new network object. Stop the node move in the new object and start the node. Dependencies: None. SCR #3622 IPCL - REL3^VER2^IPCL01^20140218 18-FEB-14 Reference: Internal Symptom: 1)ICPL connects to a PORT other then the configured port in the RADDR after multiple 4127 ECONNREFUSED errors reported on connection attempts. 2)When using SSL IPCL could send multiple 9518's to the DEST. Problem: The RADDR is passed to IP address conversion proc in the following form port:ip address in ascii. When converting the ascii port number to an internal format the ascii port is moved into a buffer on the stack. The buffer was not initialized and if the port was 4 bytes it is possible that a left over value in the 5th byte could be a valid ascii numeric and would be converted. If there happend to be a listener on that port on the target stack a connection would complete. Log message was incorrectly stating that the connection was accepted instead of allocated. 2) The connection handshake flag was not initalized and the conn complete proc did not check for SSL before sending the 9518 message. Change: Added code to initialize the buffer to spaces. Also change the log message that indicates a connection was allocated as opposed to accepted. 2) Added code to initialized the connection handshake flag. Added code in the connection completion proc to check for SSL before sending the 9518. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: N/A. SCR #3625 IPSC - REL3^VER2^IPSC01^20140218 18-FEB-14 IPCL - REL3^VER2^IPCL01^20140218 Reference: Internal Symptom: The IPSC or IPCL protocol receive an "unknown event (INV^INPFRMT)" in unusual circumstances while processing an input message. Event number 5005 (similar to the below) may be logged followed by a state machine trace. Event #5005: Line L1A^LINE01 unknown event occurred, fsm 1, current state 3, event type 17 Last state machine trace event #4000: fsm : RECV state : 0003-IAUDIT^PENDING event : 0017-INV^INPFRMT nextstate: 5535-UNKNOWN STATE action : 5535-UNKNOWN Event INV^INPFRMT was being handled in the RECEIVNG state where it would normally occur. Unusual configuration and message content caused it to occur in the IAUDIT^PENDING state where it was not handled. A trap is forced, the stack trace would be similar to the below. Depending on timing, the log events mentioned above may be queued and may not log. 0 TAL #PROGRAMMATIC^DUMP.#1117(DLIB01TS) + %HCI 1 TAL #NETDUMP.#20081(EXEC01TS) + %H3I 2 TAL #IPSC^RECV^FSM.#2149(IPSC00TS) 3 TAL #IPSC^RECV^EVAL^STREAM.#2047(IPSC00TS) 4 TAL #IPSC^RECV^FSM.#2170(IPSC00TS) + %H4I 5 TAL #IPSC^RECV^EVAL^RCV^STATUS.#2075(IPSC00TS) 6 TAL #IPSC^RECV^ROUTE^MSG^EVAL^RCV.#2314(IPSC00TS) 7 TAL #IPSC^RECV^FSM.#2178(IPSC00TS) + %H4I 8 TAL #IPSC^IO.#1346(IPSC00TS) 9 TAL #IPSC^DATACOM.#457(IPSC00TS) 10 TAL #INTERUPT^LINE.#6915(DCOM01TS) + %H6I 11 TAL #REL3^VER2^EXEC01^20140115.EXECUTE.#5042(EXEC01TS) 12 TAL #REL3^VER2^EXEC01^20140115.#5409(EXEC01TS) Change: Added a line to the state machine that handles event "INV^INPFRMT", in the IAUDIT^PENDING state, in the same manner it handled that event in the RECEIVING state. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3627 IPSC - REL3^VER2^IPSC01^20140218 18-FEB-14 IPCL - REL3^VER2^IPCL01^20140218 Reference: Internal Symptom: On some occasions, when a SSL station is stopped, event #6085 is logged showing message failure 105 or 112 for the station that was stopped. 14-02-21;18:14:47.317 \SYS.$P1AN ACI.XPNET.3200 6085 Station S1A^SSLSTA1 msg 80 from S1A^SSLSTA1 dropped, failure 105 Change: Cleared an internal pointer in the station table (cur^msg), and returned memory on that pointer when SSL handshake sends complete. This prevents a memory leak which otherwise occurs. Used logic similar to that used when normal traffic sends complete. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: none SCR #3635 TCPTPLO TCPTPLS - n30tcpl.tcp18ps TCPTPLO - n30tcpl.tcp18po Reference: Needed to recompile Symptom: didn't pull in the last message created Problem: wasn't showing message 2129 Change: recompiled the source to create a new tplo file Dependencies: none SCR #3626 IPCL - REL3^VER2^IPCL02^20140228 28-FEB-14 IPSC - REL3^VER2^IPSC02^20140228 ONCF - STA - REL3^VER2^ONCF^STA02^20140218 ONCF - SYS - REL3^VER2^ONCF^SYS02^20140218 BASE - REL3^VER2^BASE^REL03^20140218 GLOBAL - N32GLBL.GLBL03TG - N32GLBL.GDDL02DS NCPI - S32NCPI.NCP02TS - S32NCPI.NCPI02DS - S32NCPI.NETCMD02 - S32NCPI.NCPRSP02 - S32NCPI.NETRSP02 - S32NCPI.OBJ02TS - S32NCPI.RN02TS - S32NCPI.REL02TS - S32NCPL.NCPL02DS - S32NCPL.NCPL02TS - S32NCPL.NCPL02TG - S32NCPL.PARS02TG - S32NCPL.PREL02TG SVNCS - S32NCS.SNCS01TS SVNCSP - S32NCSP.TABA01XS - S32NCSP.TABC01XS - S32NCSP.NSP1XS SVNCSP24 - S32NSEC.NSP01XS NCSPREPT - S32NSEC.RPT01XS NETCJRD - S32CJRP.CJRP01TS Reference: Case #1523035 Symptom: RA-UPP-EPS-INTG (EPS platform) - XPNET does not send response back to UPP consumer Problem: When a UPP consumer sends a transaction to BASE24-eps, it comes into XPNET via a listener/inbound TCP/IP station and is sent to the IS process. The IS process creates a response and sends it to an outbound/client XPNET station (not the inbound station the message came in on). Since the XPNET msg userdata in the response contains a connection id tag from the inbound station, when the outbound XPNET station code looks at the connection ID tag, it doesn't match and XPNET drops the message, thinking it is being sent to the wrong station. XPNET actually creates a msg failure 109, but since the SIS code (by design) sets the msg disposition fail action to discard in the response, the message is dropped quietly. Change: Added code that reflects a new station attribute that will indicate whether that station can ignore the connection ID validtaion. The new station attribute is IGNORECONNID and can be set to ON/OFF. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: N/A. SCR #3629 IPCL - REL3^VER2^IPCL02^20140228 18-FEB-14 NSTP - REL3^VER2^NSTP02^20140218 BASE - REL3^VER2^BASE^REL03^20140218 Reference: Internal Symptom: IPCL status detail was not returning the local IP address for the command. Problem: The Local IP address was not being updated after the connection completed. Change: Added code to call getsockname after the connect_nw completion and then update the IPCL local address with the returned IP address. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: N/A. SCR #3639 IPCL - REL3^VER2^IPCL03^20140730 30-JUL-14 Reference: Internal Symptom: Network Dumps. Problem: An action statement in the ipcl^send^fsm proc case statement was missed. A^0^EV^SHUTD^EVT^SEND^L -> call ipcl^send^ev^shutd^evt^send( sta, conn^cb ); The following stack trace occurs in the ZZSA file. #8 0xfffffffff904cd00 in UNKNOWN_FUNCTION_NAME_ () #9 0x70ad11b0:0 in PROGRAMMATIC^DUMP (TRAP=) at \K9.$DATA01.U32DLIB.DLIB01TS:1117 #10 0x70fea490:0 in NETDUMP (PARAMETER_MASK$=-9223372036854775808, DUMP^CODE=9616, OBSOLETE=, FORM^ADDR=0x0, P1=, P2=, P3=, P4=, P5=, P6=) at \K9.$DATA01.N32EXEC.EXEC01TS:20081 #11 0x709224a0:0 in IPCL^SEND^FSM (PARAMETER_MASK$= STA=0x66067628, CONN^CB=0x65e59608, EVENT=, MSG=0xffffffffffffffff) at \K9.$DATA01.N32IPCL.IPCL02TS:4238 #12 0x709438d0:0 in IPCL^TASK^SEND^DATA^COMPLETE.HANDLE^SENDNW^ERROR () at \K9.$DATA01.N32IPCL.IPCL02TS:6927 #13 0x709430a0:0 in IPCL^TASK^SEND^DATA^COMPLETE (STA=0x66067628, CONN^CB=0x65e59608) at \K9.$DATA01.N32IPCL.IPCL02TS:7027 #14 0x708fa920:0 in IPCL^IO (STA=, CONN^CB=0x65e59608) at \K9.$DATA01.N32IPCL.IPCL02TS:1506 #15 0x708eec30:0 in IPCL^DATACOM (REQ=0, LIN=0x660c55e0, STA=0x66067628, MSG=0x0) at \K9.$DATA01.N32IPCL.IPCL02TS:641 #16 0x70dddf80:0 in INTERUPT^LINE (PARAMETER_MASK$=, REQ=0, LIN=0x660c55e0, STA=0x0, MSG=0x0) at \K9.$DATA01.N32DCOM.DCOM02TS:6916 #17 0x709d3e10:0 in REL3^VER2^EXEC01^20140115.EXECUTE (LIN=) at \K9.$DATA01.N32DCOM.DCOM02TS:3175 #18 0x7094fcc0:0 in REL3^VER2^EXEC01^20140115 () at \K9.$DATA01.N32EXEC.EXEC01TS:5563 (eInspect 1,1014): Change: Added the following code to IPCL^SEND^FSM. A^0^EV^SHUTD^EVT^SEND^L -> call ipcl^send^ev^shutd^evt^send( sta, conn^cb ); Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None. SCR #3638 SSLCLI - rel3^ver0^sslc25^20140730 30-JUL-14 SSLSRV rel3^ver0^ssls27^20140730 SSLLIBI - U10SSLL1.SSLL21 Reference: CASE # 1651176 Symptom: error 26 was occurring Problem: Since the error 26 fix was done as a special the change did not get pulled into the new library with the Heartbleed fix. Change: Rebind in the new SSL library. Implementation: Move in the new SSLCLI/SSLSRV modules. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously stopped stations. Dependencies: None \need off;\need SCR #3656 SSLCLI - rel3_ver0_sslc27_150527 27-MAY-15 SSLSRV - rel3_ver0_ssls29_150527 SSLLIB - T0000G06_13_STGSSLLIB_08MAY2015_V5R4_SPCL Reference: 1968799 Symptom: the SSLLIB was not completing the SHUTDOWN_NW() back to the SSLCLI. Problem: When an application issues ins_ssl_shutdown_nw() and the send_nw() for the closing alert sent by the library completes with the FE_EPIPE, the library doesn't send the shutdown completion to the application. Change: Properly send the shutdown completion to the application when the send_nw() for the closing alert completes with the FE_PIPE. Application will receive a proper shutdown completion when the send_nw() for the closing alert completes with the FE_PIPE. Implementation: Move in the new SSLCLI/SSLSRV modules. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously stopped stations. Dependencies: None \need off;\need SCR #3659 SSLCLI - rel3_ver0_sslc28_150727 27-JUL-15 SSLSRV - rel3_ver0_ssls30_150727 SSLLIB - T0000G06_13_STGSSLLIB_29JUN2015_V5R4_SPCL A description of your fixes are as follows: * Fix the AuthorityKeyIdentifier certificate checks Change Request: CR680 Case #: 02018237 Issue: A certificate with a KeyIdentifier in the AuthorityKeyIdentifier extension, that also had an authCertSerialNumber but not a certissuer would be wrongfully rejected. Solution: Accept certificates that have KeyIdentifier in the AuthorityKeyIdentifier extension regardless of whether they have both authCertSerialNumber and certissuer or not. Expected Result: Certificates with a KeyIdentifier in the AuthorityKeyIdentifier extension not being rejected for having authCertSerialNumber only. (55yymmdd 201555-CR680) * Changes to prevent LogJam attack on the DHE key exchange Change Request: CR679 Case #: N/A Issue: When server sends a DH modulus smaller than 1024 bits, it might be susceptible to a LogJam attack. Solution: Send 2048 bit p modulus when acting as a server, and reject modulus smaller than 1024 bits when acting as a client. Expected Result: Server will be able to handle connections from clients that expect larger modulus, and client will reject smaller modulus received from a server. (55yymmdd 201555-CR679) * Fix the missing shutdown_nw() completion for an application when the send_nw for the closing alert completes with FE_EPIPE Change Request: CR669 Case #: 01968799 Issue: When an application issues ins_ssl_shutdown_nw() and the send_nw() for the closing alert sent by the library completes with the FE_EPIPE, the library doesn't send the shutdown completion to the application. Solution: Properly send the shutdown completion to the application when the send_nw() for the closing alert completes with the FE_PIPE. Expected Result: Application will receive a proper shutdown completion when the send_nw() for the closing alert completes with the FE_PIPE. (55150915 201555-CR669) Implementation: Move in the new SSLCLI/SSLSRV modules. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously stopped stations. Dependencies: None \need off;\need SCR #3661 SSLCLI - rel3_ver0_sslc29_150915 15-SEP-15 SSLSRV - rel3_ver0_ssls31_150915 SSLLIB - T0000H06_03_STGSSLLIB_31AUG2015_V5R5 Reference: case #2095575 Symptom: Mandate to Support TLS12 for SSLLIBs. Problem: None. Change: * Reference: Internal SafeTGate SSL Library and STGSSL NonCRE Library now implement RFC7366 - TLS Encrypt-then-MAC extension. Change Request: CR644 RPE #: 07664 Issue: The current MAC-then-encrypt approach has been subject to security vulnerabilities per RFC7366. Solution: Support the extension and provide a new parameter ENCRYPTTHENMACONLY to configure whether a connection will be accepted with a partner that does not offer the encrypt-then-MAC extension. If ENCRYPTTHENMACONLY is configured as YES, then if the partner does not offer the extension, the connection shall be terminated. If NO (default) then STGSSL will attempt to use the encrypt-then-MAC extension, but will not require it if the partner does not support it. Expected result: TLS connections (version TLS10 and higher) support the encrypt-then-MAC extension for improved security. (55150831 201555-CR644) Implementation: Move in the new SSLCLI/SSLSRV modules. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously stopped stations. Dependencies: None. \need off;\need SCR #3664 SSLCLI - rel3_ver0_sslc30_151015 15-OCT-15 - T0000H06_03_STGSSLLIB_16OCT2015_V5R5_SPCL SSLSRV - rel3_ver0_ssls32_151015 - T0000H06_03_STGSSLLIB_16OCT2015_V5R5_SPCL Change Request: CR724 Issue: Incoming records with message sizes close to 16K in length were being incorrectly rejected when using the TLS 1.2 protocol. Solution: Ensure that TLS1.2 is added to TLS1.1 for checking the explicit initialisation vector is taken into account when checking the maximum plain text message length overflow. Expected Result: Received TLS records of size close to maximum of 16K not being rejected when using TLS 1.2. (56yymmdd 201556-CR724) scr #3672 TCPCLI/SSLCLI - rel3_ver0_sslc32_230316 23-mar-16 rel3_ver0_tcpc51_230316 Reference: Case #2225532 Symptom: A RECV_COMP event occurred while in the SEND_PEND state. Caused an impossible event 20. Problem: In the TCPCLI state machine code was not done to allow for a RECV_COMP in the SEND_PEND state logic. Change: Changed code to handle a RECV_COMP event in the SEND_PEND state. Implementation: Move in the new SSLCLI/TCPCLI modules. Stop associated XPNET stations. Stop and re-start SSLCLI/TCPCLI processes. Re-start the previously stopped stations. Dependencies: None. SCR #3654 BASE - REL3^VER2^BASE^REL06^20150514 14-MAY-15 REL3^VER2^EXEC02^20150514 REL3^VER2^NSTP03^20150514 GLOBAL - N32GLBL.GLBL05 N32GLBL.GDDL03 IPCL - REL3^VER2^IPCL04^20150514 IPSL - REL3^VER2^IPSL01^20150514 IPSC - REL3^VER2^IPSC03^20150514 Reference: Internal Symptom: In rare circumstances, when a backup takeover occurs after an Internal TCP Client or Server station was started, the protocol may not clean up and recover properly. Problem: The most likely place where this can happen is if the internal Client protocol suspends after a Connect attempt fails. In this case the protocol closes the socket, suspends, and re-opens the socket when re-instated. During the suspension interval there is no socket, therefore no IOCB, so the NonStop routines are unable to cleanup on takeover and notify the protocol. Audit completion tags may also not be cleaned up in rare situations. Change: Moved the "takeover notify tag" out of the IOCB and to the LINE. The protocol will set that tag independent of the IOCB (set today when fes_socket_nw is called). It is set in "mark up" and cleared in "close down". Changed NSTP to remove the old fields form the IOCB and change EXEC to dispatch the new tag on takeover. Takeover logic to delete this type of IOCB on takeover (because there was no checkopen) will remain. Added global "takeover^notify^processed^g" with an initial value of true. It is set to false when a takeover occurs, and true again when takeover cleanup logic is complete. Protocols ignore dispatched audit completions while cleanup is in progress (while the new flag is false). Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3655 BASE - REL3^VER2^BASE^REL06^20150514 14-MAY-15 REL3^VER2^PROC01^20150514 Reference: Internal Symptom: An illegal address trap occurs in procedure process^output^task, subproc getmessage, when the large message enhancement (scr3343) is being used and a chunk larger than the application allows in its call to NETLIB_INIT is being routed. Problem: The trap occurs when lmsg^master^relink^chunk is called param lmsg^udata^tkn has a bad address. Change: Added logic to set addressability to lmsg^udata^tkn. Implementation: Install the new BASE file on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3657 IPCL - REL3^VER2^IPCL04^20150514 14-MAY-15 IPSC - REL3^VER2^IPSC03^20150514 Reference: Internal Symptom: If auditing is running, and a CTS, IPCL, or IPSC station is stopped, or a takeover occurs, reference to an audit message could possibly be lost resulting in a very slow, probably unnoticeable, memory leak. Problem: If auditing an input message hasn't completed, and the station is stopped or has an error, or on backup takeover occurs, the leak can occur. Change: Returned memory and cleaned up references to the message in the appropriate places. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3658 GLOBAL - N32GLBL.GLBL05 25-JUN-15 BASE - REL3^VER2^BASE^REL06^20150514 REL3^VER2^DCOM03^20150514 IPCL - REL3^VER2^IPCL04^20150514 IPSC - REL3^VER2^IPSC03^20150514 Reference: Internal Symptom: When using the Internal TCP protocols and the SSL option, in rare circumstances an SSL error 59 can occur. 15-06-23;18:27:12.712 \SYSTEM.$P1AN ACI.XPNET.3300 6430 Response code 59 (buffer too small) from SSL library procedure SSL_RECV for station S1A^TCP01, line L1A^TCP01. Problem: The SSL library must receive a full SSL/TLS record before the data can be decrypted. In some cases the library must buffer data until the next receive completion if that record is split between multiple receives. The IPCL and IPSC protocols did not expect to receive more decrypted data from the SSL library than was just received from TCP, so the buffer given to the SSL library did not allow for the "extra" buffered data that the SSL library might return in some cases. Change: Increase buffer sizes to allow for buffering of SSL/TLS data. Implementation: Install the new files on the XPNET subvol. Rebuild the NETWORK object using the NETB file. Dependencies: None SCR #3678 SSLCLI - REL3_VER0_SSLC33_050716 05-JUL-16 SSLSRV - REL3_VER0_SSLS34_050716 SSLLIB - T0000G06_13_STGSSLLIB_27JUN2016_V5R5_SPCL Reference: case # 02335340 Symptom: The TLS 1.2 implementation does not send the signatue_algorithms extension Problem: if the client supports only the default hash and signature_algorithms it may omit the signature_algorithms extension. If the server doesn't have the certificate the connection closes. Change: A change was made to the ssllib. Implementation: Move in the new SSLCLI/SSLSRV module. Stop associated XPNET stations. Stop and re-start SSLCLI/SSLSRV processes. Re-start the previously Stopped stations. Dependencies: None.